Scalable resource discovery and reconfiguration for distributed computer networks

ABSTRACT

A method is provided for discovering resources in a network of user nodes. According to the method, a resource request to be published is received at a first user node of the network, and it is determined (e.g., randomly) whether or not to send the resource request to a server node. When it is determined not to send the resource request to the server node, the resource request is forwarded to a second user node of the network through a direct connection. When it is determined to send the resource request to the server node, the resource request is sent to the server node for publication. Also provided is a user node for use in a computer network of the type that includes user nodes and at least one server node, with each user node being connected to at least one other user node through a direct connection.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to the inventor's application “SYSTEMAND METHOD FOR RESPONDING TO RESOURCE REQUESTS IN DISTRIBUTED COMPUTERNETWORKS,” Ser. No. ______, now ______, which was filed on the same dayas the present application and commonly assigned herewith toInternational Business Machines Corporation. This related application isincorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to computer networks, and morespecifically to a framework for scalable resource discovery and dynamicreconfiguration in distributed computer networks.

[0004] 2. Description of Related Art

[0005] Computer networks such as the Internet allow users to shareresources such as files and hardware. The expansion of the Internet andthe adoption of standards for the World Wide Web have made the viewingand downloading of files by a user almost effortless. The user need notknow any programming languages. By simply running an Internet browser,the user only needs to point and click to view and download desiredfiles. The availability of such programs allows for easy collaborationand file sharing among like-minded individuals separated by greatdistances over a distributed computer network, which can literally spanthe entire globe.

[0006] Conventionally, a distributed computer network is set up to havea client/server framework. In particular, each user is a client that canaccess a server node over the network and, with the properauthorization, publish files to the server node. Once a file ispublished to the server node, other clients on the network can accessthe server node to view or download the file. Additionally, the servernode can allow a client to automatically send a file to another clientthat is reachable over the network. The client simply sends the file tothe server node along with information identifying the desiredrecipient, and the server node sends the file on to the correspondingclient. The server node can also be used to allow the clients to sharehardware resources such as a printer.

[0007] With such a client/server framework, the server node is chargedwith providing security. For example, the server node must insure thatonly authorized clients can use the network resources (e.g., downloadfiles), and that only proper files are published. Additionally, theserver node represents a single point of failure. Thus, in anyclient/server environment in which reliability is required, the servernode must be of industrial strength and have redundant systems toprevent system shutdowns and data loss. Further, because allclient-to-client resource transfers pass through the server node, theadding of another client to the network puts an additional burden on theserver node and degrades network performance.

[0008] In such a client/server framework, the clients have littleprivacy. Typically, the server node requires authentication beforeallowing a client to access network resources. Once the client hasprovided authentication credentials, the server node can easily log allof the network activity of the client. For example, the server nodecould keep a log of all files uploaded and downloaded by the client.Even if access by unauthenticated clients is allowed, the server nodecan use any of various unique identification techniques to track clientactivity over time. For example, the server node can place a uniquecookie on the client and later use the cookie to identify the clienteach time it accesses the server node.

[0009] One solution to some of the drawbacks of the conventionalclient/server framework is provided by a “viral” network. In such anetwork, a user node connects to one or more known hosts that areparticipating in a highly interconnected virtual network. Then, the usernode itself becomes a host node that can respond to requests forresources and available hosts. Each user in the network forwardsresource requests to all known neighboring nodes, so as to potentiallypropagate each request throughout the entire network. For example, theGnutella system employs such a viral network framework. Gnutella has apublished network protocol and provides users a client/serverapplication (available at http://gnutella.wego.com) that allows eachuser to act as a host node in a file sharing network. The Gnutellasystem can be used to securely distribute commercial content that isprotected by encryption and licensing.

[0010] Viral networks are based on peer-to-peer communication.Peer-to-peer is a communications model in which each party has similarcapabilities and either party may initiate a communication session. Forexample, the Gnutella application employs peer-to-peer communication toallow users to exchange files with one another over the Internet. Thepeer-to-peer model used in a viral network relies on each peer (i.e.,user node) having knowledge of at least one of the other peers in thenetwork. When searching for a resource such as a file, a peer sends aresource request to other known peers, which in turn pass it on to theirknown peers and so on to propagate the request throughout the network. Apeer that has the resource and receives the request can send theresource (or a message indicating its availability) back to therequesting peer. Because such a framework offers independence from acentralized network authority (e.g., server node), users in a viralnetwork have enhanced privacy and the single point of failure iseliminated.

[0011]FIG. 1 shows an exemplary viral network. Each node in the networkrepresents a user that acts both as a client and host, and is connectedwith one or more other nodes. When a first node 210 desires a particularresource (e.g., file), the first node 210 issues a request to all knownnodes 202, 204, 206, and 208, which in turn do the same. For example,the request reaches a second node 212 by being passed in successionthrough nodes 208, 216, and 218. If the second node 212 has therequested resource, it responds by sending an appropriate message to thefirst node 210 (e.g., back the same path that the request traversed).Because a node having the requested resource has been identified, thefirst node 210 can initiate a direct peer-to-peer connection with thesecond node 212 in order to download the resource. Throughout the viralnetwork, any number of such resource requests, acknowledgments, andtransfers can occur simultaneously.

[0012] While viral networks offer enhanced privacy and eliminate asingle point of failure, the framework has drawbacks related toscalability. In a large, decentralized viral network, efficient resourcediscovery breaks down as the number of participating nodes increases.More specifically, are source request can only propagate from node tonode, and each node only propagates the request to a relatively smallnumber of other nodes. To control network traffic and preventunreasonable response times, a practical system must employ a“time-to-live” or some limit on the number of times a request can beforwarded (i.e., a maximum number of peer hops). This effectivelydisconnects any two nodes or groups of nodes that are separated by apath that would require a request to propagate through an unreasonablylarge number of intermediary nodes. Further, any such limit on requestpropagation makes it impossible to perform an exhaustive search for aresource, because such a search would require the request to bepropagated to all of the nodes in the network.

[0013] Additionally, there has recently been proposed a content-basedpublish-subscribe messaging infrastructure that utilizes an informationflow graph. For example, the Gryphon system (described athttp://www.research.ibm.com/gryphon) has been developed by the assigneeof the present invention. This system provides a content-basedsubscription service and performs message brokering by merging thefeatures of distributed publish/subscribe communications and databasetechnology. At the core of the Gryphon system is an information flowgraph that specifies the selective delivery of events, thetransformation of events, and the generation of new events.

[0014]FIG. 2 shows an exemplary content-based publish-subscribemessaging infrastructure that utilizes information flow graphs. In thissystem, stocks trades derived from two information sources NYSE andNASDAQ are combined, transformed, filtered and delivered to subscribingclients. For example, one user 312 may subscribe to themessage-brokering server 302 and request to receive all stock trades onboth the NYSE and NASDAQ that have a value of over one million dollars.The message broker 302 receives raw stock trade information such asprice and volume from the NYSE 324 and NASDAQ 326.

[0015] Based on the information request of the user 312, the server 302merges the stock trade information from the two sources, transforms theraw price and volume information into value information for each trade,and then filters the derived values to produce the subset of trades thatare valued at over one million dollars. In a similar manner, eachsubscribing user (e.g., nodes 304, 306, and 308) specifies its owncriteria, and the message-brokering server 302 performs informationselection, transformation, filtering, and delivery in order to provideeach user with the requested information.

[0016] While the publish-subscribe messaging infrastructure of FIG. 2provides good scalability for a messaging system with a large number ofusers, as in the conventional client/server framework the users havelittle privacy. All users must identify themselves when subscribing tothe system and all information is delivered to the user through thecentralized server. Thus, the centralized server can easily maintain alog of all users of the system and the exact information that eachdesires and receives. The centralized message-brokering server alsorepresents a single point of failure for the system.

SUMMARY OF THE INVENTION

[0017] In view of these drawbacks, it is an object of the presentinvention to remove the above-mentioned drawbacks and to provide anetwork framework that provides scalable resource discovery and sharing.A scalable messaging infrastructure is provided to address scalabilityand performance issues, while most features of a decentralized networkare preserved. At least one publish-subscribe server node is provided ina decentralized network not as a central authority, but as a messaginginfrastructure layer. Thus, scalability can be achieved in adecentralized network.

[0018] One embodiment of the present invention provides a method fordiscovering resources in a network of user nodes. According to themethod, a resource request to be published is received at a first usernode of the network, and it is determined whether or not to send theresource request to a server node. When it is determined not to send theresource request to the server node, the resource request is forwardedto a second user node of the network through a direct connection. Whenit is determined to send the resource request to the server node, theresource request is sent to the server node for publication. In apreferred embodiment, the determination of whether or not to send theresource request to the server node is a random decision made by thefirst user node.

[0019] Another embodiment of the present invention provides a user nodefor use in a computer network of the type that includes user nodes andat least one server node, with each of the user nodes being connected toat least one other user node through a direct connection. The user nodeincludes a receiving interface for receiving a resource request to bepublished, control means for deciding whether or not to send theresource request to the server node, and at least one transmittinginterface for selectively forwarding the resource request to a seconduser node of the network through a direct connection or sending theresource request to the server node for publication. The transmittinginterface forwards the resource request to the second user node when thecontrol means decides not to send the resource request to the servernode, and sends the resource request to the server node for publicationwhen the control means decides to send the resource request to theserver node. In one preferred embodiment, the control means randomlyselects one of the other user nodes of the network to be the second usernode to which the resource request is forwarded.

[0020] Other objects, features, and advantages of the present inventionwill become apparent from the following detailed description. It shouldbe understood, however, that the detailed description and specificexamples, while indicating preferred embodiments of the presentinvention, are given by way of illustration only and variousmodifications may naturally be performed without deviating from thepresent invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021]FIG. 1 is a diagram of an exemplary viral network;

[0022]FIG. 2 is a diagram of an exemplary content-basedpublish-subscribe messaging infrastructure;

[0023]FIG. 3 is a diagram of scalable network framework according to apreferred embodiment of the present invention;

[0024]FIG. 4 is a flow chart of a process for obtaining a resourcewithin a scalable network framework in accordance with a firstembodiment of the present invention;

[0025]FIG. 5 is a flow chart of a process for obtaining a resourcewithin a scalable network framework in accordance with a secondembodiment of the present invention;

[0026]FIG. 6 is a flow chart of a process for obtaining a resourcewithin a scalable network framework in accordance with a thirdembodiment of the present invention;

[0027]FIG. 7 is a diagram of scalable network framework showing anexemplary implementation of part of the process of FIG. 6; and

[0028]FIG. 8 is a diagram of scalable network framework showing anexemplary implementation of another part of the process of FIG. 6.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0029] Preferred embodiments of the present invention will be describedin detail hereinbelow with reference to the attached drawings.

[0030]FIG. 3 shows a scalable network framework according to a preferredembodiment of the present invention. As shown, the framework includes apublish-subscribe server node 402 and multiple user nodes (e.g., 404,406, and 410). In embodiments of the present invention, the server node402 can be implemented by a single server or by a “server cloud” that ismade up of any number of servers. The individual servers of such aserver cloud can be connected to one another and to the Internet invarious ways and can even be separated by great distances so as toprovide an appropriate level of service and advantageous features suchas data and path redundancy.

[0031] Within this framework, a user node 416 joins the network bycontacting the publish-subscribe server node 402 and subscribing tocertain “channels” of messages. Additionally, the joining user node 416solicits connections and then directly connects with at least one otheruser node 410, 418, and 420 (e.g., based on some criteria such asgeographic location, connection speed, or common interests). In thismanner, all of the user nodes in the network are connected to thecentralized publish-subscribe server node for messaging (not shown forclarity) and to one another through peer-to-peer connections that form adecentralized viral-type resource sharing network.

[0032]FIG. 4 is a flow chart of a process for obtaining a resourcewithin such a scalable network framework in accordance with a firstembodiment of the present invention. Whenever a first user node 416 inthe network desires are source (e.g., file), are source request (orquery) is sent to the server node 402 (step S10), and the server node402 publishes the resource request by sending it to all of the usernodes that are subscribed to the channel corresponding to that type ofrequest (step S12). A second user node 422 that receives the request andis willing to provide the resource contacts the first user node 416(step S14), and the first and second user nodes 416 and 422 set up apeer-to-peer connection to provide the requested resource to the firstuser node 416 (step S16). In this manner, the publish-subscribemessaging infrastructure layer allows a resource request to reach nodesthat are separated from the requesting node by a direct-connect paththat includes a very large number of intermediary nodes.

[0033] Thus, in the scalable network framework provided by the presentinvention, efficient resource discovery is maintained when the number ofuser nodes in the network increases. At the same time, the resourcesthemselves are not published to the server and the actual resourcesharing does not involve the server, so the demands on the server areless than in the conventional client/server framework. Furthermore,because each search request is published to all of the user nodes thatsubscribe to the relevant channel, it is possible to perform anexhaustive (or at least very extensive) search for the requestedresource within an acceptable time frame in a network that contains avery large number of user nodes.

[0034] In preferred embodiments, the publish-subscribe messaginginfrastructure supports two types of “channels”, or shared data streams.The first type of channel is a “node discovery channel” that is used tosupport the discovery of other user nodes in the decentralized network.To join the network, a user node announces itself using thepublish-subscribe messaging infrastructure of the server node. Inparticular, a join announcement from the new user node is routed via theserver node to one or more of the node discovery channels to solicitconnections from other user nodes. Thus, the publish-subscribeinfastructure functions as a general purpose transport layer (like alayer above IP) that establishes connections to other user nodes toaccomplish the broadcasting of join announcements.

[0035] Such join announcements can be divided among individual nodediscovery channels based on categories such as geographic location,network connection speed, types of resources available, and/or commoninterests. Thus, the new user node can discover remote user nodes (bothgeographically and with respect to network hops) and when connecting canfavor nodes with the desired type of resources or acceptableconnectivity attributes. Further, because each join announcement is onlysent to the user nodes subscribed to certain channels, the user nodes ofa very large network are not constantly flooded with join announcements.

[0036] The second type of channel is a “resource request channel” thatis used to optimize the publication of resource requests. As explainedabove, the server node publishes each resource request by sending it toall of the user nodes that are subscribed to a particular channel (orchannels). These resource request channels can be divided into a richtaxonomy of resource types in order to allow the user nodes toeffectively filter out undesired requests. Further, rather than reachingevery user node in the network, the use of resource request channelsallows a resource request to only reach a relevant subset of user nodes(i.e., those that subscribe to the relevant channel or channels).

[0037] Thus, a user node that only desires to share technicaldocumentation is not bombarded with requests for multimedia content.Depending on the application, the user node and/or the server node candetermine the channel or channels on which to publish an individualannouncement or resource request. Further, in preferred embodiments, achannel exists merely by virtue of being published to by a user node.Thus, any user node can create anew resource channel and then promoteits availability for subscription in any conventional manner (e.g.,through a web site, news group, television, or direct mail advertising).

[0038]FIG. 5 is a flow chart of a process for obtaining a resourcewithin a scalable network framework in accordance with a secondembodiment of the present invention. Whenever a first user node 416 inthe network desires a resource (e.g., file), a resource request is sentto the server node 402 (step S10), and the server node 402 publishes theresource request by sending it to all of the user nodes that aresubscribed to the channel corresponding to that type of request (stepS12). Additionally, in the second embodiment the first node 416 alsosends the resource request to all of the user nodes 410, 418, and 420 towhich it is connected in the decentralized network.

[0039] This process is repeated with each user nodes that receives therequest passing it on to the user nodes to which it is connected, so asto propagate the request through the user nodes of the decentralizednetwork (step S11). For example, the request reaches a second user node404 by being passed in succession through nodes 410 and 414. Further, insome embodiments each user node that receives the resource request fromthe server node (e.g., user node 422) also sends the resource request toall of the user nodes to which it is connected in the decentralizednetwork. If the second user node 404 receives the request (eitherthrough user node propagation or from the server node) and is willing toprovide the resource, the second user node 404 contacts the first usernode 416 (step S14), and a peer-to-peer connection is set up to sharethe requested resource (step S16).

[0040] Thus, in the second embodiment resource requests are bothpublished through the messaging infrastructure layer (as in the firstembodiment) and propagated through the user nodes of the decentralizednetwork. Because this dual path process offers an alternative to therequest propagation path that passes through the centralized servernode, the single point of failure is eliminated. In other words, theresource request is propagated to other user nodes even when the servernode is down. Further, in the second embodiment, it is not necessary forall of the user nodes to be connected to, or even know about thepresence of the publish-subscribe infrastructure. Such a user node canmerely forward resource requests to all of the user nodes to which it isconnected. This feature allows the second embodiment to be implementedin an existing network without requiring the modification of all usernodes.

[0041]FIG. 6 is a flow chart of a process for obtaining a resourcewithin such a scalable network framework in accordance with a thirdembodiment of the present invention. In this embodiment, resourcerequests are not sent directly to the server node in order to giveenhanced privacy to the requesting user node. Whenever a resource (e.g.,file) is desired in the third embodiment, the requesting first user node410 sends a resource request to a second user node 414 to which it isconnected in the decentralized network (step S20), as shown by thedashed arrows in FIG. 7. The second user node 414 then determineswhether to send the request to the publish-subscribe server node 402 orto another user node to which it is connected in the decentralizednetwork (step S22). Preferably, all of the user nodes are connected tothe centralized publish-subscribe server node for messaging (not shownfor clarity).

[0042] If it is decided not to send to the server node 402, then thesecond user node 414 forwards the resource request to another user node420 to which it is connected (step S20), as shown in FIG. 7. Thisforwarding process is repeated with each user node that receives theresource request making the same determination (step S22). When a thirduser node 416 decides to send to the server node 402, the resourcerequest is sent to the server node 402 (step S24), and the server node402 publishes the resource request by sending it to all of the usernodes that are subscribed to the channel corresponding to that type ofrequest (step S26).

[0043] In preferred embodiments, each determination of whether or not tosend the request to the publish subscribe server node is a “random”decision made by the user node based on a weighting factor of between 0and 1 that gives the probability that the request will be sent to theserver node. For example, if the weighting factor is 0.25, then there isa 25% chance that the user node will send the request to the server nodeand a 75% chance that the request will be forwarded to another usernode. Thus, on average a weighting factor of 0.25 should cause resourcerequests to be forwarded to other user nodes three times before beingsent to the publish-subscribe server node. The value of the weightingfactor is set based on factors such as the desired level of privacy.Further, the weighting factor can be a fixed value that is usedthroughout the network or can be set by the user nodes on a per messagebasis. Other criteria such as a maximum number of forwards or a maximumelapsed time can also be incorporated into the determination that ismade by each user node receiving the request.

[0044] In further embodiments, the determination of whether or not tosend the request to the publish-subscribe server node is made based onsome other criteria such as a fixed number of forwards. For example, inone embodiment each resource request is always forwarded through threeuser nodes and then sent to the publish-subscribe server node.Preferably, whenever a resource request is to be forwarded on to anotheruser node, the choice of which other user node will receive theforwarded request is made through a random selection of one of the usernodes to which the forwarding user node is connected.

[0045] After the resource request is published by the server node 402, afourth user node 422 that receives the request and is willing to providethe resource contacts the first user node 410. More specifically, asshown in FIG. 8 the fourth user node 422 sends a response to the thirduser node 416 (step S28), which had sent the resource request to theserver node 402 for publication. The third user node 416 forwards theresponse to the user node 420 from which it received the resourcerequest, and this forwarding process is repeated until the responsereaches the first user node 410 (step S30). At this point, the firstuser node 416 can contact the fourth user node 422 to set up a directpeer-to-peer connection to share the requested resource (step S32).

[0046] In preferred embodiments, the response from the user node havingthe resource contains metadata concerning the resource match. When theresponse is received, the requesting user node evaluates the metadataand then decides whether to make a direct connection with the respondingnode to share the resource itself(e.g., download the requested file). Ifmultiple responses are received, the requesting user node can evaluatethe metadata in each response and then select one or more of theresponding user nodes based on any criteria (e.g., past experience,order received, connection speed, or physical location).

[0047] Additionally, in preferred embodiments, responses from user nodeshaving the resource are routed through existing connections (such as theone the request had traversed through the server node), and a newpoint-to-point connection is only established to actually transfer theresource. Otherwise, with each responding user node initiating a newpoint-to-point connection, the user node receiving the responses couldbe overwhelmed whenever a large number of responses are received.Alternatively, the server node could set up a matching “one-time”response channel or a permanent response channel to be used by usernodes responding to the resource request. The publishing of responsesover a permanent response channel would facilitate “passive” user nodesthat archive responses of possible interest for future use.

[0048] Because resource requests are forwarded through one or more otheruser nodes rather than being sent directly to the server node, the thirdembodiment offers privacy to requesting user nodes. The actual user noderequesting a resource remains anonymous to the server node, so theserver node cannot keep track of which users are sharing (or evenrequesting) which resources. As in a conventional viral network, in thethird embodiment only a user node that actually provides the resourcehas knowledge of the resource sharing and the identity of the requestingnode. Further, unlike a conventional viral network, in the thirdembodiment the use of a publish-subscribe messaging infrastructure layerallows for efficient resource discovery in a network having a very largenumber of user nodes. Thus, the present invention allows scalability tobe achieved in a decentralized network while enhanced user privacy ismaintained.

[0049] The embodiments of the present invention described above requiresome mechanism for identifying individual messages. In preferredembodiments, every message (i.e., resource request or response) isassigned a unique identification number. For example, one embodimentemploys an algorithm developed by Microsoft Corporation that allows eachuser node to individually generate globally-unique message identifiers(GUIDs) that are very likely to be globally unique. Additionally, eachuser node must store (e.g., in a table) at least a limited history offorwarded messages in order to allow responses (possibly including theresource itself) to reach the user node that sent a message through thesame path. Further, some embodiments include a mechanism to prevent thelooping of a resource request. For example, the globally-unique messageidentifiers GUIDs and node history tables can easily be used to createan anti-looping mechanism.

[0050] While the embodiments of the present invention described aboverelate to a single server node, multiple publish-subscribe server nodescan be provided in the network to further minimize “point of failure”concerns. Further, competing providers may coexist in the network byoperating different server nodes and competing for user nodesubscriptions. Additionally, the features of the different embodimentsdescribed above can be combined for further applications. For example,one embodiment of the present invention includes both the randomizedrequest forwarding of the third embodiment and the dualpropagation/publication of the second embodiment. Other design choices,such as network protocols, forwarding criteria, and membership criteria,could easily be adapted.

[0051] The present invention can be realized in hardware, software, or acombination of hardware and software. Any kind of computer system—orother apparatus adapted for carrying out the methods described herein—issuited. A typical combination of hardware and software could be ageneral purpose computer system with a computer program that, whenloaded and executed, controls the computer system such that it carriesout the methods described herein.

[0052] The present invention can also be embedded in a computer programproduct, which comprises all the features enabling the implementation ofthe methods described herein, and which—when loaded in a computersystem—is able to carry out these methods. In the present context, a“computer program” includes any expression, in any language, code ornotation, of a set of instructions intended to cause a system having aninformation processing capability to perform a particular functioneither directly or after either or both of the following: a) conversionto another language, code, or notation; and b) reproduction in adifferent material form.

[0053] Each computer system may include one or more computers and acomputer readable medium that allows the computer to read data,instructions, messages, or message packets, and other computer readableinformation from the computer readable medium. The computer readablemedium may include non-volatile memory such as ROM, Flash memory, a hardor floppy disk, a CD-ROM, or other permanent storage. Additionally, acomputer readable medium may include volatile storage such as RAM,buffers, cache memory, and network circuits. Furthermore, the computerreadable medium may include computer readable information in atransitory state medium such as a network link and/or a networkinterface (including a wired network or a wireless network) that allow acomputer to read such computer readable information.

[0054] While there has been illustrated and described what are presentlyconsidered to be the preferred embodiments of the present invention, itwill be understood by those skilled in the art that various othermodifications maybe made, and equivalents maybe substituted, withoutdeparting from the true scope of the present invention. Additionally,many modifications maybe made to adapt a particular situation to theteachings of the present invention without departing from the centralinventive concept described herein. Furthermore, an embodiment of thepresent invention may not include all of the features described above.Therefore, it is intended that the present invention not be limited tothe particular embodiments disclosed, but that the invention include allembodiments falling within the scope of the appended claims.

What is claimed is:
 1. A method for discovering resources in a networkof user nodes, said method comprising the steps of: receiving a resourcerequest to be published at a first user node of the network; determiningwhether or not to send the resource request to a server node; forwardingthe resource request to a second user node of the network through adirect connection, when it is determined not to send the resourcerequest to the server node; and sending the resource request to theserver node for publication, when it is determined to send the resourcerequest to the server node.
 2. The method as defined in claim 1, whereinin the determining step, the determination of whether or not to send theresource request to the server node is a random decision made by thefirst user node.
 3. The method as defined in claim 2, wherein in thedetermining step, the random decision is made based on a weightingfactor corresponding to the probability that the first user node willdecide to send the resource request to the server node.
 4. The method asdefined in claim 1, wherein the forwarding step includes the sub-stepsof: randomly selecting one of the user nodes to which the first usernode is connected to be the second user node; and forwarding theresource request from the first user node to the second user nodethrough a direct connection.
 5. The method as defined in claim 1,further comprising the step of publishing the resource request to atleast some of the user nodes of the network via the server node.
 6. Themethod as defined in claim 5, wherein in the publishing step, the servernode publishes the resource request to all of the user nodes of thenetwork that are subscribed to one or more selected resource requestchannels.
 7. The method as defined in claim 1, further comprising thestep of repeating the steps of determining and forwarding until in thedetermining step a user node that received the resource request decidesto send the resource request to the server node.
 8. The method asdefined in claim 1, further comprising the steps of: sending theresource request to be published from a requesting user node, whichdesires the request resource, to the first user node; and sending anidentical resource request from the requesting user node to all of theuser nodes to which the requesting user node is connected through directconnections.
 9. A machine-readable medium encoded with a program fordiscovering resources in a network of user nodes, said programcontaining instructions for performing the steps of: receiving aresource request to be published at a first user node of the network;determining whether or not to send the resource request to a servernode; forwarding the resource request to a second user node of thenetwork through a direct connection, when it is determined not to sendthe resource request to the server node; and sending the resourcerequest to the server node for publication, when it is determined tosend the resource request to the server node.
 10. The machine-readablemedium as defined in claim 9, wherein in the determining step, thedetermination of whether or not to send the resource request to theserver node is a random decision made by the first user node.
 11. Themachine-readable medium as defined in claim 10, wherein in thedetermining step, the random decision is made based on a weightingfactor corresponding to the probability that the first user node willdecide to send the resource request to the server node.
 12. Themachine-readable medium as defined in claim 9, wherein the forwardingstep includes the sub-steps of: randomly selecting one of the user nodesto which the first user node is connected to be the second user node;and forwarding the resource request from the first user node to thesecond user node through a direct connection.
 13. The machine-readablemedium as defined in claim 9, wherein said program further containsinstructions for performing the step of publishing the resource requestto at least some of the user nodes of the network via the server node.14. The machine-readable medium as defined in claim 13, wherein in thepublishing step, the server node publishes the resource request to allof the user nodes of the network that are subscribed to one or moreselected resource request channels.
 15. The machine-readable medium asdefined in claim 9, wherein said program further contains instructionsfor performing the step of repeating the steps of determining andforwarding until in the determining step a user node that received theresource request decides to send the resource request to the servernode.
 16. The machine-readable medium as defined in claim 9, whereinsaid program further contains instructions for performing the steps of:sending the resource request to be published from a requesting usernode, which desires the request resource, to the first user node; andsending an identical resource request from the requesting user node toall of the user nodes to which the requesting user node is connectedthrough direct connections.
 17. A user node for use in a computernetwork of the type that includes a plurality of user nodes and at leastone server node, with each of the user nodes being connected to at leastone other user node through a direct connection, said user nodecomprising: a receiving interface for receiving a resource request to bepublished; control means for deciding whether or not to send theresource request to the server node; and at least one transmittinginterface for selectively forwarding the resource request to a seconduser node of the network through a direct connection or sending theresource request to the server node for publication, wherein thetransmitting interface forwards the resource request to the second usernode when the control means decides not to send the resource request tothe server node, and sends the resource request to the server node forpublication when the control means decides to send the resource requestto the server node.
 18. The user node as defined in claim 17, whereinthe control means randomly decides whether or not to send the resourcerequest to the server node.
 19. The user node as defined in claim 18,wherein the control means randomly decides based on a weighting factor.20. The user node as defined in claim 17, wherein the control meansrandomly selects one of the other user nodes of the network to be thesecond user node to which the resource request is forwarded.